3. Mailheaders

Let’s have a look at a typical mail sent via smtp.postman.i2p – delivered into a local mailbox:

Return-Path:
X-Original-To: postman@mail.i2p
Delivered-To: postman@mail.i2p
Received: from localhost (localhost [127.0.0.1])
by smtp.postman.i2p (I2pMailer) with ESMTP id A2F8F38811B
for ; Sat, 18 Sep 2004 17:56:25 (UTC)
From: testuser
Organization: mail.i2p
To: postman@mail.i2p
Subject: Testmail
Date: Sat, 18 Sep 2004 17:55:41 +0200
User-Agent: KMail/1.6.2
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain;
charset=”us-ascii”
Content-Transfer-Encoding: 7bit
Message-Id: <200409181755.41048.postman@mail.i2p>

Hello,
this is just a test to see it in action

In general mail headers contain administrative information about a mail. When you write a mail with your mail program (commonly called a Mail
User Agent, MUA for short), the MUA will create header lines along with the message you typed. A blank line is used to separate the header lines from the body.

A few of the header lines will later be seen by the recipient as sender and subject and things like priority or the date the message has been created or sent.

According to RFC2822 a few header lines MUST exist in a mail:

  1. From: describes the sender of this mail. Usually it contains your name along with your mail address. A normal MUA will use the address and name from the active configuration profile. Your From: address will also be used within the SMTP dialogue as MAIL FROM: address. The sender address used in the SMTP dialogue is called “envelope-sender” while the address printed in the From: header is called “header-sender”. Normally the envelope sender and the sender “printed” on the mail itself are equal.

  2. To: One or more recipients of a mail. If there’s more then one recipient, they’re separated by commas. Most MUAs allow you to send mail to more than one recipient by using the Cc: (Carbon Copy) and the Bcc: (Blind Carbon Copy) fields. At least one recipient in one of those fields is needed. The MUA picks ALL recipients in ALL those fields and uses them for the SMTP dialog to tell the mail relay which addresses your mail is to be sent to. The mail server does not check these fields to determine the recipients of a mail after it’s queued. The MUA has to present the list of recipients BEFOREHAND.

  3. Date: The Date of the message creation. Usually in the human readable form: Day, Date Month Year, Time (OFFSET to UTC)

  4. Message-ID:An unique identifier for the message. Normally it’s up to the MUA to create a message-ID. If the MUA does not create one, the MTA will insert the header line instead. Message-IDs can contain sensitive information, like local host names, local user names, local dates or timezones. Check the message-IDs your MUA creates. The ID shown in the header was created by KMail/1.6 and only discloses the local time of creation in its tag.

    5. Most MUAs create many more lines though, because they’re needed to declare the mail content or priority. Commonly added headers include:

    1. Subject: The Subject of the mail message. This header line is one of the few that will be shown by all MUAs along with From: and To:. But it does need to exist.

    2. Organization: The Organization the sender belongs to. Normally you are asked to fill in this information during the creation of your account. Before you send mail, check your account settings. Organization should be left empty or contain something like mail.i2p or another fantasy name that cannot be associated with your real life identity.

    3. User-Agent: This header line will be added by the MUA and indicates what kind of software has been used by the sender to compose the message. This field gets automatically filled. Most MUAs don’t allow it to be removed or edited.

    4. Reply-To: This header line contains the reply address for a mail. It will be only filled when the reply address differs from the original From: address. Most MUAs allow you to enter e Reply-To address. Please check that it is left empty or filled with a valid mail.i2p address.

    5. In-Reply-To: / References:If you answer a mail a fellow I2P user sent to you, it is quite likely that your MUA will add an In-Reply-To: or References: header line. This header line does not contain mail addresses or host names, but the message-ID or message-IDs (in the case of a mail thread with multiple replies and re-replies) that your mails refers to. It’s not considered critical if the message-IDs created by all participating MUAs do not contain critical information either.

    6. X- header lines: Both MUA and Mailrelay are free to add custom lines that are not described in the standards. Depending on the MUA you’re using, more or fewer X-headers are added. Common used headers are X-Priority and X-Status, X-Mailer, mostly added by Microsoft MUAs. On the server side, X- headers are commonly used for mail tagging, i.e. tagging a mail as spam or virus-checked (X-Spam-Status, X-Virusscanned,...). To find about your MUA inspect a freshly composed mail in the outbox and check for X- header lines. None of the *nix MUAs we tested created X-headers by default.

    7. Content Description / MIME:Since E-mails can contain plain text, html messages, even attached files, the MIME standard is used for content declaration in mails. This standard is widely applied in all MUAs. In general MIME headers do not contain much harmful information. There is always a MIME-Version: header line. It is followed by a Content-Type: or a Content-Disposition: line, depending on the mail being a single message or a multi-parted message.

      8. While the MUA composes the mail and adds quite a bunch of (mostly harmless if done rightly) header lines, the Mail Transfer Agent (Mail server/Relay, or MTA for short) receives the mail from the MUA. This is done via the Simple Mail Transfer Protocol. During an SMTP session some additional data is being exchanged between MUA and MTA. Let’s have a look. Lines starting with < << are sent by the server and received by the client. Lines starting with >>> are sent by the client and received by the server..


      < << 220 mail.i2p ESMTP I2PNet Mailservice
      >>> ehlo localhost
      < << 250-mail.i2p
      < << 250-PIPELINING
      < << 250-SIZE 8388608
      < << 250-ETRN
      < << 250-AUTH LOGIN PLAIN
      < << 250-AUTH=LOGIN PLAIN
      < << 250 8BITMIME
      >>> MAIL FROM: testbed@mail.i2p
      < << 250 Ok
      >>> RCPT TO: postman@mail.i2p
      < << 250 Ok
      >>> DATA
      < << 354 End data with .
      >>> From: testuser
      >>> Organization: mail.i2p
      >>> To: postman@mail.i2p
      >>> Subject: Testmail
      >>> Date: Sat, 18 Sep 2004 17:55:41 +0200
      >>> User-Agent: KMail/1.6.2
      >>> MIME-Version: 1.0
      >>> Content-Disposition: inline
      >>> Content-Type: text/plain;
      >>> charset=”us-ascii”
      >>> Content-Transfer-Encoding: 7bit
      >>> Message-Id: <200409181755.41048.postman@mail.i2p>
      >>>
      >>> Hello,
      >>> this is just a test to see it working
      >>>
      >>>.
      < << 250 Ok Message queued as 09FBAD27A2

      As you can see, the client announces the sender of the mail and the recipient(s) of a mail before it sends the mail itself to the server. The MTA does not work with any address related information of the header. After transmitting the sender/recipient, the client starts transmitting the mail as it has been composed. Transmission ends with a dot on a line by itself. If the mail relay accepts the transmission it has to decide what to do with it. In our example, the MTA comes to the conclusion that the recipient is a local mailbox and delivers it locally.

      During the whole process of queuing/routing and delivering the MTA adds a few header lines to the mail itself. Those header lines are inserted to track mail loops or delivery loops and to create a traceinfo about the path a mail has taken from its beginning to the final delivery. You cannot influence the creation or content of those lines, the explanation should serve your comprehensive understanding of the mail header.

      1. Return-Path: Contains the sender address the client used for the MAIL FROM command during the SMTP session. If a mail turns out finally to be undeliverable, the resulting bounce message will be sent to the Return-Path and not to the From: address in the mail header. In a normally composed mail From: address and Return-Path address are however the same.

      2. Received: Every MTA receiving the mail will add its own Received: line on top of all the others. A normally sent mail contains 2-5 received lines, indicating that the mail was handled by this number of MTAs on its way from start to destination. The Received: lines contains quite useful information allowing mail administrators to trace back the path of a mail to spot problems or to judge the probability of a mail being SPAM or not. The received line contains: the sending host (with his HELO host-name, DNS name and IP), the receiving host, the protocol used(SMTP/ESMTP/QMQP/LMTP…), time and queueid.

      3. Delivered-To:This header line is added when the mail leaves the MTA system and is delivered into a mailbox. Mailbox delivery is normally done by a component called Mail Delivery Agent (short MDA. Most modern mail systems bundle MTA and MDA). The MDA adds this header to prevent local delivery loops. If the mail somehow gets resent (forwarded) to another address and then back again to the old address (maybe because of another forward pointing back to the original address), the mail system is not allowed to overload. Thus the MDA looks for Delivered-To: headers in every mail to deliver. If it finds a Delivered-To line with a mailbox address matching the recent target address, the mail will be bounced immediately.

        4. What happens on the MTA side? – What if I haven’t got it properly but still want to use the service?

        Let us assume that you configured your client OK. This will make sure, that no really compromising data will be leaked to the recipient of the mails you send. In addition to that the MTA itself can help with a set of measures to support the anonymity of users towards the recipients of mails. mtp.postman.i2p does the following every time a mail passes

        1. All User-Agent: and X-Mailer: header lines are automatically removed and replaced by the line X-Mailer:

          2. smtp.postman.i2p Official I2P Mailer.
        2. All X- header lines are completely removed
        3. All message IDs are replaced by server-side generated message-IDs
        4. All Date: tags are removed and replaced by server-side generated Dates in UTC
        5. All Received: tags are removed (apart from the very last one)

          6. This will lead to a sanitizing of mail headers in an acceptable form.

          ^Back